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Micro-loop Prevention by Introducing a Local Convergence Delay 
Abstract 


This document describes a mechanism for link-state routing protocols 
that prevents local transient forwarding loops in case of link 
failure. This mechanism proposes a two-step convergence by 
introducing a delay between the convergence of the node adjacent to 
the topology change and the network-wide convergence. 


Because this mechanism delays the IGP convergence, it may only be 
used for planned maintenance or when Fast Reroute (FRR) protects the 
traffic during the time between the link failure and the IGP 


convergence. 


The mechanism is limited to the link-down event in order to keep the 
mechanism simple. 


Simulations using real network topologies have been performed and 
show that local loops are a significant portion (>50%) of the total 
forwarding loops. 

Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 7841. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
https://www.rfc-editor.org/info/rfc8333. 
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Introduction 


Micro-loops and some potential solutions are described in [RFC5715]. 
This document describes a simple targeted mechanism that prevents 
micro-loops that are local to the failure. Based on network 
analysis, local micro-loops make up a significant portion of the 
micro-loops. A simple and easily deployable solution for these local 
micro-loops is critical because these local loops cause some traffic 
loss after an FRR alternate has been used (see Section 3.1). 


Consider the case in Figure 1 where S does not have an LFA (Loop-Free 
Alternate) to protect its traffic to D when the S-D link fails. That 
means that all non-D neighbors of S on the topology will send to S 
any traffic destined to D; if a neighbor did not, then that neighbor 
would be loop-free. Regardless of the advanced FRR technique used, 
when S converges to the new topology, it will send its traffic toa 
neighbor that is not loop-free and will thus cause a local micro- 
loop. The deployment of advanced FRR techniques motivates this 
simple router-local mechanism to solve this targeted problem. This 
solution can work with the various techniques described in [RFC5715]. 


Diele C 

| | 

| | 5 

| | 

Sees B 
Figure 1 


In Figure 1, all links have a metric of 1 except the B-C link, which 
has a metric of 5. When the S-D link fails, a transient forwarding 
loop may appear between S and B if S updates its forwarding entry to 
D before B does. 

Terminology 
1. Acronyms 

FIB: Forwarding Information Base 

FRR: Fast Reroute 

IGP: Interior Gateway Protocol 


LFA: Loop-Free Alternate 


LSA: Link State Advertisement 
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LSP: Link State Packet 
MRT: Maximally Redundant Tree 
oFIB: Ordered FIB 
PLR: Point of Local Repair 
PLSN: Path Locking via Safe Neighbors 
RIB: Routing Information Base 
RLFA: Remote Loop-Free Alternate 
SPF: Shortest Path First 
TTL: Time to Live 
2.2. Requirements Language 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 
"OPTIONAL" in this document are to be interpreted as described in 


BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 
capitals, as shown here. 


3. Side Effects of Transient Forwarding Loops 


Even if they are very limited in duration, transient forwarding loops 
may Cause significant network damage. 


3.1. FRR Inefficiency 


In Figure 2, we consider an IP/LDP routed network. 


D 

1 | 

| i 

A ------ B 
dia Ion 
| | | 
E-------- C 

| 1 

1 | 

S 

Figure 2 
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An RSVP-TE tunnel T, provisioned on C and terminating on B, is used 
to protect the traffic against C-B link failure (the IGP shortcut 
feature, defined in [RFC3906], is activated on C). The primary path 
of T is C->B and FRR is activated on T, providing an FRR bypass or 
detour using path C->E->A->B. On router C, the next hop to D is the 
tunnel T, thanks to the IGP shortcut. When the C-B link fails: 


1. C detects the failure and updates the tunnel path using a 
preprogrammed FRR path. The traffic path from S to D becomes 
S->E->C->E->A->B->A->D. 


2. In parallel, on router C, both the IGP convergence and the TE 
tunnel convergence (tunnel path recomputation) are occurring: 


* The tunnel T path is recomputed and now uses C->E->A->B. 
* The IGP path to D is recomputed and now uses C->E->A->D. 


3. On C, the tail-end of the TE tunnel (router B) is no longer on 
the shortest-path tree (SPT) to D, so C does not continue to 
encapsulate the traffic to D using the tunnel T and updates its 
forwarding entry to D using the next-hop E. 


If C updates its forwarding entry to D before router E, there would 
be a transient forwarding loop between C and E until E has converged. 


Table 1 describes a theoretical sequence of events happening when the 
B-C link fails. This theoretical sequence of events should only be 
read as an example. 


4+------------ 4+-------- 4R--------------------- 4----------------------- + 

| Network | Time | Router C Events | Router E Events | 

| Condition | | | | 

+------------ +-------- +--------------------- +----------------------- + 

| sp | | | | 

| Traffic OK | | | | 

| | | | | 

| S->D NES. SA Link B-C fails | Link B-C fails | 

| Traffic | | | | 
lost | | 

| | to+20 | C detects the 

| | ms | failure 

| | | 
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| S-»D | to+40 | C activates FRR | 

| Traffic OK | ms | | | 

| | t0+50 | C updates its local | 

| | ms | LSP/LSA | 

| | | | | 

| | to+60 | C floods its local | 

| | ms | updated LSP/LSA | 

| | t0+62 | C schedules SPF | 

| | ms | (100 ms) | | 

| | | | | 

| | to+87 | | E receives LSP/LSA | 

| | ms | | from C and floods it | 

| | | | | 
t0+92 E schedules SPF (100 

ms ms) 

| | | | | 

| | t0+163 | C computes SPF | 

| | ms | | | 

| | | | | 
t0+165 C starts updating 

| | ms | its RIB/FIB | 

| | | | | 

| | t0+193 | | E computes SPF | 

| | ms | | | 

| | | | | 
t0+199 E starts updating its 

| Ne dl | ee | 

| | | | | 

| S->D | t0o+255 | C updates its | 

| Traffic | ms | RIB/FIB for D | 

| lost | | | | 

| | t0+340 | C convergence ends | 

| Non | | 

| S->D | t0+443 | | E updates its RIB/FIB | 

| Traffic OK | ms | | for D 

| | t0+470 | | E convergence ends | 

| | ms | | | 

4------------ 4-------- q4--------------------- 4----------------------- t 


Table 1 
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The issue described here is completely independent of the FRR 
mechanism involved (e.g., TE FRR, LFA/RLFA, MRT, etc.) when the 
primary path uses hop-by-hop routing. The protection enabled by FRR 
works perfectly but only ensures protection until the PLR has 
converged (as soon as the PLR has converged, it replaces its FRR path 
with a new primary path). When implementing FRR, a service provider 
wants to guarantee a very limited loss of connectivity time. The 
example described in this section shows that the benefit of FRR may 
be completely lost due to a transient forwarding loop appearing when 
PLR has converged. Delaying FIB updates after the IGP convergence 
(1) may allow the FRR path to be kept until the neighbors have 
converged and (2) preserves the customer traffic. 


3.2. Network Congestion 


In Figure 3, when the S-D link fails, a transient forwarding loop may 
appear between S and B for destination D. The traffic on the S-B 
link will constantly increase due to the looping traffic to D. 
Depending on the TTL of the packets, the traffic rate destined to D, 
and the bandwidth of the link, the S-B link may become congested in a 
few hundreds of milliseconds and will stay congested until the loop 
is eliminated. 


1 
D ------ C 
| | 
1 | | 5 
| | 
A, =="8 ====== B 
/ | 1 
F E 
Figure 3 


The congestion introduced by transient forwarding loops is 
problematic as it can affect traffic that is not directly affected by 
the failing network component. In Figure 3, the congestion of the 
S-B link will impact some customer traffic that is not directly 
affected by the failure, e.g., traffic from A to B, F to B, and E to 
B. Class of service may mitigate the congestion for some traffic. 
However, some traffic not directly affected by the failure will still 
be dropped as a router is not able to distinguish the looping traffic 
from the normally forwarded traffic. 
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4. Overview of the Solution 


This document defines a two-step convergence initiated by the router 
detecting a failure and advertising the topological change in the 
IGP. This introduces a delay between network-wide convergence and 
the convergence of the local router. 


The solution described in this document is limited to local link-down 
events in order to keep the solution simple. 


This ordered convergence is similar to the ordered FIB (oFIB) 
approach defined in [RFC6976], but it is limited to only a "one-hop" 
distance. As a consequence, it is more simple and becomes a local- 
only feature that does not require interoperability. This benefit 
comes with the limitation of eliminating transient forwarding loops 
involving the local router only. The mechanism also reuses some 
concepts described in [PLSN]. 


5. Specification 

5.1. Definitions 
This document refers to the following existing IGP timers. These 
timers may be standardized or implemented as a vendor-specific local 
feature. 


o LSP GEN TIMER: The delay between the consecutive generation of two 
local LSPs/LSAs. From an operational point of view, this delay is 
usually tuned to batch multiple local events in a single local 
LSP/LSA update. In IS-IS, this timer is defined as 
minimumLSPGenerationInterval [ISO10589]. In OSPF version 2, this 
timer is defined as MinLSInterval [RFC2328]. It is often 
associated with a vendor-specific damping mechanism to slow down 
reactions by incrementing the timer when multiple consecutive 
events are detected. 


o SPF DELAY: The delay between the first IGP event triggering a new 
routing table computation and the start of that routing table 
computation. It is often associated with a damping mechanism to 
Slow down reactions by incrementing the timer when the IGP becomes 
unstable. As an example, [BACKOFF] defines a standard SPF delay 
algorithm. 
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This document introduces the following new timer: 


o ULOOP DELAY DOWN TIMER: Used to slow down the local node 
convergence in case of link-down events. 


5.2. Regular IGP Reaction 


When the status of an adjacency or link changes, the regular IGP 
convergence behavior of the router advertising the event involves the 
following main steps: 


1. IGP is notified of the up/down event. 


2. The IGP processes the notification and postpones the reaction for 
LSP GEN TIMER ms. 


3. Upon LSP GEN TIMER expiration, the IGP updates its LSP/LSA and 
floods it. 


4. The SPF computation is scheduled in SPF DELAY ms. 


5. Upon SPF DELAY timer expiration, the SPF is computed, and then 
the RIB and FIB are updated. 


5.3. Local Events 


The mechanism described in this document assumes that there has been 
a single link failure as seen by the IGP area/level. If this 
assumption is violated (e.g., multiple links or nodes failed), then 
regular IP convergence must be applied (as described in Section 5.2). 


To determine if the mechanism is applicable or not, an implementation 
SHOULD implement logic to correlate the protocol messages (LSP/LSA) 
received during the SPF scheduling period in order to determine the 
topology changes that occurred. This is necessary as multiple 
protocol messages may describe the same topology change, and a single 
protocol message may describe multiple topology changes. As a 
consequence, determining a particular topology change MUST be 
independent of the order of reception of those protocol messages. 

How the logic works is left to the implementation. 


Using this logic, if an implementation determines that the associated 
topology change is a single local link failure, then the router MAY 
use the mechanism described in this document; otherwise, the regular 
IP convergence MUST be used. 
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In Figure 4, let router B be the computing router when the link B-C 
fails. B updates its local LSP/LSA describing the link B-C as down, 
C does the same, and both start flooding their updated LSPs/LSAs. 
During the SPF_DELAY period, B and C learn all the LSPs/LSAs to 
consider. B sees that C is flooding an advertisement that indicates 
that a link is down, and B is the other end of that link. B 
determines that B and C are describing the same single event. Since 
B receives no other changes, B can determine that this is a local 
link failure and may decide to activate the mechanism described in 
this document. 


Figure 4 
5.4. Local Delay for Link-Down Events 


This document introduces a change in step 5 (see list in Section 5.2) 
so that, upon an adjacency or link-down event, the local convergence 
is delayed compared to the network-wide convergence. The new step 5 
is described below: 


5. Upon SPF_DELAY timer expiration, the SPF is computed. If the 
condition of a single local link-down event has been met, then an 
update of the RIB and the FIB MUST be delayed for 
ULOOP_DELAY_DOWN_TIMER ms. Otherwise, the RIB and FIB SHOULD be 
updated immediately. 


If a new convergence occurs while ULOOP_DELAY_DOWN_TIMER is running, 
ULOOP_DELAY_DOWN_TIMER is stopped, and the RIB/FIB SHOULD be updated 
as part of the new convergence event. 


As a result of this addition, routers local to the failure will 
converge slower than remote routers. Hence, it SHOULD only be done 
for a non-urgent convergence, such as administrative deactivation 
(maintenance) or when the traffic is protected by FRR. 


6. Applicability 
As previously stated, this mechanism only avoids the forwarding loops 


on the links between the node local to the failure and its neighbors. 
Forwarding loops may still occur on other links. 
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6.1. Applicable Case: Local Loops 


In Figure 5, let us consider the traffic from G to F. The primary 
path is G->D->C->E->F. When the link C-E fails, if C updates its 
forwarding entry for F before D, a transient loop occurs. This is 
sub-optimal as it breaks C's FRR forwarding even though upstream 
routers are still forwarding the traffic to C. 


All the links have a metric of 1 
Figure 5 


By implementing the mechanism defined in this document on C, when the 
C-E link fails, C delays the update of its forwarding entry to F, in 
order to allow some time for D to converge. FRR on C keeps 
protecting the traffic during this period. When 
ULOOP_DELAY_DOWN_TIMER expires on C, its forwarding entry to F is 
updated. There is no transient forwarding loop on the link C-D. 


6.2. Non-applicable Case: Remote Loops 


In Figure 6, let us consider the traffic from G to K. The primary 
path is G->D->C->F->J->K. When the C-F link fails, if C updates its 
forwarding entry to K before D, a transient loop occurs between C and 
D. 


G---D-------- CPES F--- J ---- K 
All the links have a metric of 1 except B-E=15 
Figure 6 


By implementing the mechanism defined in this document on C, when the 
link C-F fails, C delays the update of its forwarding entry to K, 
allowing time for D to converge. When ULOOP_DELAY_DOWN_TIMER expires 
on C, its forwarding entry to F is updated. There is no transient 
forwarding loop between C and D. However, a transient forwarding 
loop may still occur between D and A. In this scenario, this 
mechanism is not enough to address all the possible forwarding loops. 
However, it does not create additional traffic loss. Besides, in 
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some cases -- such as when the nodes update their FIB in the order C, 
A, D because the router A is quicker than D to converge -- the 
mechanism may still avoid the forwarding loop that would have 
otherwise occurred. 


Simulations 


Simulations have been run on multiple service-provider topologies. 
We evaluated the efficiency of the mechanism on eight different 
service-provider topologies (different network size and design). 
Table 2 displays the gain for each topology. 


4---------- +------ + 
| Topology | Gain | 
+---------- +------ + 
T1 TES 
T2 81% 
| T3 | 62% | 
| T4 | 50% | 
| T5 | 70% | 
| T6 | 70% | 
T7 59% 
T8 77% 
4---------- +------ + 
Table 2 


We evaluated the gain as follows: 


o 


We considered a tuple (link A-B, destination D, PLR S, backup 
next-hop N) as a loop if, upon link A-B failure, the flow from a 
router S upstream from A (A could be considered as PLR also) to D 
may loop due to convergence time difference between S and one of 
its neighbors N. 


We evaluated the number of potential loop tuples in normal 
conditions. 


We evaluated the number of potential loop tuples using the same 
topological input but taking into account that S converges after 
N. 


The gain is the relative number of loops (both remote and local) 
we succeed in suppressing. 
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For topology 1, implementing the local delay prevented 71% of the 
transient forwarding loops created by the failure of any link. The 
analysis shows that all local loops are prevented and only remote 
loops remain. 


8. Deployment Considerations 
Transient forwarding loops have the following drawbacks: 


o They limit FRR efficiency. Even if FRR is activated within 50 ms, 
as soon as the PLR has converged, the traffic may be affected by a 
transient loop. 


o They may impact traffic not directly affected by the failure (due 
to link congestion). 


The local delay mechanism is a transient forwarding loop avoidance 
mechanism (like oFIB). Even if it only addresses local transient 
loops, the efficiency versus complexity comparison of the mechanism 
makes it a good solution. It is also incrementally deployable with 
incremental benefits, which makes it an attractive option for both 
vendors to implement and service providers to deploy. Delaying the 
convergence time is not an issue if we consider that the traffic is 
protected during the convergence. 


The ULOOP_DELAY_DOWN_TIMER value should be set according to the 
maximum IGP convergence time observed in the network (usually 
observed in the slowest node). 


This mechanism is limited to link-down events. When a link goes 
down, it eventually goes back up. As a consequence, with this 
mechanism deployed, only the link-down event will be protected 
against transient forwarding loops while the link-up event will not. 
If the operator wants to limit the impact of transient forwarding 
loops during the link-up event, it should make sure to use specific 
procedures to bring the link back online. As examples, the operator 
can decide to put the link back online outside of business hours, or 
it can use some incremental metric changes to prevent loops (as 
proposed in [RFC5715]). 
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9. Examples 


We consider the following figure for the examples in this section: 


D 

T || F----X 
AS 1] 
A ------ B 
10 | E 
| | 
E-------- C 

| 1 

1 | 

S 

Figure 7 


The network above is considered to have a convergence time of about 1 
second, so ULOOP DELAY DOWN TIMER will be adjusted to this value. We 
also consider that FRR is running on each node. 


9.1. Local Link-Down Event 


Table 3 describes the events and their timing on routers C and E when 
the link B-C goes down. It is based on a theoretical sequence of 
events that should only been read as an example. As C detects a 
single local event corresponding to a link-down event (its LSP + LSP 
from B received), it applies the local delay down behavior, and no 
micro-loop is formed. 
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4R------------ Ho 4R--------------------- 4R---------------------- + 
| Network | Time | Router C Events | Router E Events | 
| Condition | | | | 
+------------ Ho 4R--------------------- 4R---------------------- + 
| S->D | | | | 
| Traffic OK | | | | 
| | | | | 
| S->D | to | Link B-C fails | Link B-C fails | 
Traffic 
lost 

| | | | 
| | to+20 | C detects the 

| | ms | failure | 
| | | | 
| S->D | t0+40 | C activates FRR | 

| Traffic OK | ms | | | 
| | t0+50 | C updates its local | 

| | ms | LSP/LSA | | 
| | | | | 
| | t0+53 | C floods its local | 

| | ms | updated LSP/LSA | 

| t0+60 | C schedules SPF | 

| ms | (100 ms) | | 
| | | | | 
| | t0+67 | C receives LSP/LSA | 

ms from B and floods 
qu 
| | | | | 
| | t0«-87 | | E receives LSP/LSA | 
| | ms | | from C and floods it | 
| | | | | 
t0+90 E schedules SPF (100 
ms ms) 

| | | | | 
| | to+161 | C computes SPF | 

| | ms | | | 
| | | 

t0+165 C delays its 

| ms | RIB/FIB update (1 | 

| | | m | | 
| | t0+193 | | E computes SPF | 
| | ms | | | 
| | t0+199 | | E starts updating | 
| | ms | | its RIB/FIB | 
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| | | | | 
| | t0+443 | | E updates its | 
| | ms | | RIB/FIB for D | 
| | t0+470 | | E convergence ends | 
| | ms | | | 
| | | | | 
| | t0+1165 | C starts updating | 
| | ms | its RIB/FIB | | 
| | t0+1255 | C updates its | 
| | ms | RIB/FIB for D | | 
| | | | | 
| | t0+1340 | C convergence ends | 
| | ms | | | 
4+—------------ +--------- 4+—--------------------- Ho + 
Table 3 
Similarly, upon B-C link-down event, if LSP/LSA from B is received 
before C detects the link failure, C will apply the route update 
delay if the local detection is part of the same SPF run. Table 4 
describes the associated theoretical sequence of events. It should 
only been read as an example. 
4+—------------ 4+—--------- 4+—--------------------- Ho + 
| Network | Time | Router C Events | Router E Events | 
| Condition | | | | 
+—------------ +--------- 4+--------------------- Ho + 
| sep | | | | 
| Traffic OK | | | | 
| | | | | 
| S-»D | to | Link B-C fails | Link B-C fails | 
Traffic 
lost 
| | | | | 
| | t0+32 | C receives LSP/LSA | 
| | ms | from B and floods | 
| | | it | | 
| | t0+33 | C schedules SPF | 
| | ms | (100 ms) | | 
| | | | | 
| | t0+50 | C detects the | 
| | ms | failure | | 
| | | | | 
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| S-»D | to+55 | C activates FRR | | 
| Traffic OK | ms | | | 
| | t0+55 | C updates its local | 

| | ms | LSP/LSA | | 
| | | | | 
| | t0+70 | C floods its local | 

| | ms | updated LSP/LSA | 

| | t0+87 | | E receives LSP/LSA | 
| | ms | | from C and floods it | 
| | | | | 
| | t0+90 | | E schedules SPF (100 | 
| | ms | | ms) | 
| | | | | 

t0+135 C computes SPF 

| pe | | 
| | | | | 
| | t0+140 | C delays its | 

| | ms | RIB/FIB update (1 | | 
| | | sec) | | 
| | t0+193 | | E computes SPF | 
| p | | 
| | t0+199 | | E starts updating | 
| | ms | | its RIB/FIB | 
| | t0+443 | | E updates its | 
| | ms | | RIB/FIB for D | 
| | | | | 
| | t0+470 | | E convergence ends | 
| | ms | | | 
| | t0+1145 | C starts updating | 

| | ms | its RIB/FIB | | 
| | | | | 
| | t0+1255 | C updates its | 

| | ms | RIB/FIB for D | | 
| | t0+1340 | C convergence ends | 

| | ms | | | 
4------------ 4--------- 4--------------------- q4---------------------- t 


Table 4 
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9.2. Local and Remote Event 


Table 5 describes the events and their timing on router C and E when 
the link B-C goes down and when the link F-X fails in the same time 


March 2018 


window. C will not apply the local delay because a non-local 


topology change is also received. 


Table 5 is based on a theoretical 


sequence of events that should only been read as an example. 


+ a A IN 
| Network 
| Condition 


Traffic 
OK 


+ 
| 
| 
+ 
| 
| 
| 
| 
| 
| 
| 
| 
S->D | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 


to 


t0+69 


Litkowski, et al. 


+ 
| 
| 
+ 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 


Link B-C fails 


C detects the 
failure 


Link F-X fails 


C activates FRR 


C updates its 
local LSP/LSA 


C receives 
LSP/LSA from F 
and floods it 


C schedules SPF 
(100 ms) 


C receives 


LSP/LSA from B 
and floods it 
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+ 
| 
| 
+ 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 


A ware iul Ete aunt O A a + 
Router E Events 


Link B-C fails 


Link F-X fails 


E receives LSP/LSA from 


F, floods it and 


schedules SPF 


(100 ms) 
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S-» 
Traff 
los 


s-> 


Traff 
OK 


Litkowski, 


D 
ic 
t 


D 
xc 


et al. 


Micro- 


t0+70 
ms 


t0+117 
ms 


t0+160 
ms 


t0+165 
ms 


t0+170 
ms 


t0+173 
ms 


t0+365 
ms 


t0+443 
ms 


t0+450 
ms 


t0+470 
ms 


loop Prevention by Local Delay 


C floods its 
local updated 
LSP/LSA 


C 


C computes SPF 


C starts updating 
its RIB/FIB (NO 
DELAY) 


RIB/FIB 


C updates its 
RIB/FIB for D 


for D 


C convergence 
ends 


Table 5 
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E receives LSP/LSA from 


E floods LSP/LSA from C 


E computes SPF 


E starts updating its 


E updates its RIB/FIB 


E convergence ends 
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9.3. Aborting Local Delay 


Table 6 describes the events and their timing on routers C and E when 
the link B-C goes down. In addition, we consider what happens when 
the F-X link fails during local delay of the FIB update. C will 
first apply the local delay, but when the new event happens, it will 
fall back to the standard convergence mechanism without further 
delaying route insertion. In this example, we consider a 
ULOOP_DELAY_DOWN_TIMER configured to 2 seconds. Table 6 is based on 
a theoretical sequence of events that should only been read as an 


example. 

te SS SSS a Pea Se eae Se eS Se + 
| Network Time Router C Events Router E Events 

| Condition | 
q------------4--------4----------------------p---------------------- + 


S->D 


S->D 
Traffic 
lost 


to Link B-C fails Link B-C fails 


C detects the 
failure 


S->D 


+ + 
| | 
| | 
+ + 
m 
| | 
| | 
| | 
| | 
| | 
| | 
Traffic OK | ms | 
| | 
| | 
| | 
| | 
| | 
| | 
| | 
| | 
| | 
| | 
| | 
| | 


C activates FRR 


t0+50 C updates its local 
ms LSP/LSA 
t0+55 C floods its local 
ms updated LSP/LSA 
t0+57 C schedules SPF (100 
ms ms) 
t0+67 C receives LSP/LSA 
ms from B and floods it 
t0+87 E receives LSP/LSA 
ms from C and floods it 
t0+90 E schedules SPF (100 
ms ms) 
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t0+160 
ms 


t0+165 
ms 


t0+193 
ms 


t0+199 
ms 


t0+254 
ms 


t0+300 
ms 


t0+303 
ms 


t0+312 
ms 


t0+313 
ms 


t0+502 
ms 


t0+505 
ms 


t0+514 
ms 


t0+519 
ms 


t0+659 
ms 


C computes SPF 


C delays its RIB/FIB 
update (2 sec) 


Link F-X fails 
C receives LSP/LSA 
from F and floods it 


C schedules SPF (200 
ms) 


E receives LSP/LSA 
from F and floods it 


E schedules SPF (200 
ms) 


C computes SPF 


C starts updating 
its RIB/FIB (NO 
DELAY) 


C updates its 
RIB/FIB for D 
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E computes SPF 
E starts updating 
its RIB/FIB 


Link F-X fails 


E computes SPF 


E starts updating 
its RIB/FIB 
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E updates its | 
RIB/FIB for D | 


C convergence ends 


E convergence ends 


+ — 


Table 6 


10. Comparison with Other Solutions 


As stated in Section 4, the local delay solution reuses some concepts 
already introduced by other IETF proposals but tries to find a trade- 
off between efficiency and simplicity. This section tries to compare 
behaviors of the solutions. 


10.1. PLSN 


PLSN [PLSN] describes a mechanism where each node in the network 
tries to avoid transient forwarding loops upon a topology change by 
always keeping traffic on a loop-free path for a defined duration 
(locked path to a safe neighbor). The locked path may be the new 
primary next hop, another neighbor, or the old primary next hop 
depending on how the safety condition is satisfied. 


PLSN does not solve all transient forwarding loops (see Section 4 of 
[PLSN] for more details). 


The solution defined in this document reuses some concepts of PLSN 
but in a more simple fashion: 


o PLSN has three different behaviors: (1) keep using the old next 
hop, (2) use the new primary next hop if it is safe, or (3) use 
another safe next hop. The local delay solution, however, only 
has one: keep using the current next hop (i.e., the old primary 
next hop or an already-activated FRR path). 


o PLSN may cause some damage while using a safe next hop that is not 
the new primary next hop if the new safe next hop does not provide 
enough bandwidth (see [RFC7916]). The solution defined in this 
document may not experience this issue as the service provider may 
have control on the FRR path being used, preventing network 
congestion. 
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11. 


2s 


o PLSN applies to all nodes in a network (remote or local changes), 
while the mechanism defined in this document applies only to the 
nodes connected to the topology change. 


-2. oOFIB 


oFIB [RFC6976] describes a mechanism where the convergence of the 
network upon a topology change is ordered in order to prevent 
transient forwarding loops. Each router in the network deduces the 
failure type from the LSA/LSP received and computes/applies a 
specific FIB update timer based on the failure type and its rank in 
the network, considering the failure point as root. 


The oF IB mechanism solves all the transient forwarding loops in a 
network at the price of introducing complexity in the convergence 
process that may require careful monitoring by the service provider. 


The solution defined in this document reuses the oFIB concept but 
limits it to the first hop that experiences the topology change. As 
demonstrated, the mechanism defined in this document allows all the 
local transient forwarding loops to be solved; these represent a high 
percentage of all the loops. Moreover, limiting to one hop allows 
network-wide convergence behavior to be kept. 


IANA Considerations 
This document has no IANA actions. 
Security Considerations 


This document does not introduce any change in terms of IGP security. 
The operation is internal to the router. The local delay does not 
increase the number of attack vectors as an attacker could only 
trigger this mechanism if it already has the ability to disable or 
enable an IGP link. The local delay does not increase the negative 
consequences. If an attacker has the ability to disable or enable an 
IGP link, it can already harm the network by creating instability and 
harm the traffic by creating forwarding packet loss and forwarding 
loss for the traffic crossing that link. 
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